The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
In port-based authentication, a network end station device such as a multifunction printer, personal computer, or server cannot access a network through a physical port or logical port of a network infrastructure element, such as a router or switch, until the end station authenticates to the infrastructure element. To perform authentication, upon detecting packets on a port the infrastructure element requests the end station to provide a credential, and the infrastructure element verifies or validates the credential by communicating with an authentication, authorization and accounting (AAA) server over a protocol such as RADIUS or TACACS+.
Performing authentication requires time for the end station device and the infrastructure element to communicate several messages, for the infrastructure device to communicate with the AAA server, and for the AAA server to look up and validate the credential in a secure database. However, before the authentication process completes, other processes in the end station device may attempt to send traffic on the port. For example, in a device that uses Dynamic Host Control Protocol (DHCP) as defined in IETF RFC*, a DHCP client may attempt to send a DHCPREQUEST message to obtain a leased IP address before the authentication process completes.
In this environment, adverse consequences can occur. Upon receiving DHCP or other traffic from a non-authenticated device, an infrastructure element may shut down the port, ending all communication on the port including authentication messages, causing authentication to fail. In that event, a network administrator must use a console command or the equivalent to instruct the infrastructure element to re-open the port. This is undesirable because manual work is involved, and the end station device may be unusable on the network until the infrastructure element is re-configured. In other cases, the infrastructure element may silently drop the unauthorized traffic; as a result, the end station device may time out in seeking a dynamic address under DHCP, and then may default to a stored static IP address since it is unable to obtain a dynamic address. The use of the static IP address may provide the network device with limited connectivity or other problems.
The Microsoft Windows XP DHCP client attempts to address this issue by re-sending DHCPREQUEST packets periodically at different time intervals. However, some infrastructure elements still respond by shutting down ports that are connected to non-authenticated devices.
Prior U.S. application Ser. No. 11/544,116, filed Oct. 6, 2006, describes one possible solution to the issues identified in this section. However, the approach of the '116 application uses a delay in starting the network end station device, and the delay may be undesirable in certain situations.